In many communication systems, it is necessary to determine a type of received communication traffic, so as to verify packets of data across an interface against an interface specification or to classify traffic, for example.
Traffic type decisions are typically made on the basis of information in network headers or other overhead. Traditionally, data and other actual content of communication traffic is treated as a “black box” for the purposes of type determination. In the event that any information that would normally be included in the data portion of a communication traffic block such as a packet is required for decision making in a communication network, this information is instead tagged to the block as a header.
Although headers and other overhead tend to be foolproof and sufficient for all uses intended when a protocol is first developed, information required for decision making beyond such initial intended uses is not directly available in overhead without changing the protocol or layering on a new protocol. Full analysis of communication traffic content when the traffic overhead does not provide all required information tends to be expensive and difficult, since packets and other traffic blocks might contain only fragments of data, possibly in an unknown format.
This sort of challenge in type determination might arise, for example, where a specification does not define all protocol elements to the same level of detail, or traffic packets do not include complete protocol information in their overhead. A specification for a communication equipment control interface might explicitly define “Type”, “Parameter”, and “Allowed Values” elements for a hierarchy of Type>>Subtypes>>Parameters>>Allowed Values, but packets might not include standardized “Subtype” identifiers. Subtype determination might be a challenge, for instance, if different equipment vendors are allowed to choose in which parameter their Subtype name is stored or to not explicitly list a Subtype at all. In one currently known protocol, Subtype is conceptually a valid combination of parameters, which was given a name in the protocol specification, but is not explicitly identified in live data streams.
In the above example, without narrowing valid parameters to those that are valid for only a given Subtype instead of the generic Type, validation rules that are used to determine whether a received packet conforms to the specification could be too loose to catch anything but the most obvious errors.
One possible solution to this problem in the above example might be to develop specific software code to identify the Subtype for each special case, such as for each vendor-specific Subtype. However, this approach could be time-consuming and complicated, especially for a large number of special cases, and therefore expensive to implement. Custom software code would also have to be maintained manually as new special cases are identified. In addition, a custom special-case solution would be prone to error when faced with never-before-seen data, which is precisely when it would be used the most.
Thus, there remains a need for improved communication traffic type determination techniques.